fix(power-automate): v3.0.3 — Asia region, solution flow edits, publish state - #412

Summary

Seven bug fixes for the power-automate plugin, released as v3.0.3.

Both manifests (.plugin/plugin.json and .claude-plugin/plugin.json) and the bundled server (server/mcp.mjs) are updated together. The branch name still says v3.0.2 because the v3.0.3 fixes were added to this branch after it was opened; the shipped version is v3.0.3.

Fixes

#347 — Asia-region tenants: every operation fails

list_environments and all subsequent Flow RP calls now detect MacroRegionDerivationFailed, extract the geo name from the error, and retry against the geo-specific endpoint (for example asia.api.flow.microsoft.com). The resolved endpoint is reused for the rest of the session. Previously every operation failed for any tenant whose environments are provisioned in the Asia region.

#407 — publish_flow reports success while the flow stays Stopped

publish_flow now reads the flow back after /start and returns the observed state as actualState. If the flow did not reach Started — for example because a connection is missing or unauthenticated — the tool returns success: false with an actionable warning. Previously a 409 Conflict was mapped to alreadyStarted: true regardless of the real state.

#414, #416 — solution flows unresolvable after publishing

get_flow_context looked the Dataverse row up by the PPAPI flow id. Publishing reassigns that id while Dataverse keeps the original workflowid, so the lookup returned 404, the flow was reported as inSolution: false, and writes were routed down the PPAPI path — which cannot express a connection-reference binding.

The lookup now uses workflowEntityId and workflowUniqueId from the PPAPI response, falling back to the flow id when they are absent. This also covers the case where one flow is addressable by two valid PPAPI ids.

#415, #418 — definition edits rejected on solution flows

Two problems on the Dataverse write path:

• Host key convention. get_flow returns host.connectionName, but a flow's stored clientdata may use either connectionName or connectionReferenceName depending on how it was authored. The write now reads which convention the stored definition already uses and matches it, rather than assuming one. Writing the wrong key produced WorkflowRunActionInputsMissingProperty, naming an action the edit never touched.
• Connection references. The write no longer copies PPAPI-format connectionReferences into clientdata, which would have overwritten the Dataverse-format references already stored there.

#392, #416 — spurious "No connected connection found"

autoMergeConnectionRefs filtered Dataverse connection reference rows on a status field those rows do not have, so every candidate was dropped and the tool reported no connected connection for a connector that demonstrably had one.

The filter now understands both row shapes. Fixing it surfaced a second, latent defect: the resolved reference was built from fields Dataverse rows do not expose, yielding an undefined connection name and silently writing a malformed reference. The reference is now built from the correct fields, carries the connection reference logical name through, and raises an actionable error instead of writing a malformed reference when no id can be read.

edit_flow also now carries the flow's current connection references into the update body, and autoResolveConnectionRefs is exposed on both edit_flow and update_flow so auto-merge can be disabled by callers that supply their own references.

Testing

• 978 unit tests passing, including 7 new regression tests covering both host-key directions, the workflow id lookup and its fallback, clientdata connection references left untouched, and the auto-merge reference shape in both the resolvable and unreadable cases.
• Clean build from matow_microsoft/flow-agent main.
• Live smoke test against a real environment: passed in 16.7s.

Note for reviewers

Automated review reports "only the plugin version fields changed" because the third changed file, plugins/power-automate/server/mcp.mjs, is a 2.5 MB generated bundle that is skipped during review. All of the behaviour described above lives in that bundle; the corresponding source changes are in matow_microsoft/flow-agent.

The host-key detection for #415/#418 is inferred from the reported reproductions rather than confirmed against a tenant holding a connectionReferenceName-shaped flow. It is written to match whatever the stored definition already uses, so it degrades to current behaviour rather than breaking if that inference is wrong, but confirmation against a real affected flow would be worthwhile.